1. Field of the Invention
The present invention relates to telecommunications services and more particularly to a method and system for sending messages in response to network activity.
2. Description of Related Art
Advances in telecommunications have enabled a number of special services to be made available to telecommunications subscribers. Examples of such services include abbreviated dialing, which allows a subscriber to reach a party by dialing less than the entire telephone number of that party, call forwarding, in which calls directed to the subscriber may be forwarded to another line, terminating call screening, which allows the subscriber to specify certain times during which incoming calls are to be rejected, and originating call screening, in which calls to certain telephone numbers are barred. In general, special telecommunications services (“services”) encompass those service features that do more than simply place or terminate telephone calls as dialed.
In the past, special telecommunications services were governed and provided for exclusively by the network switches or other entities that routed calls from one location to another. Such switches or other entities are usually at least part of a “serving system” that provides service for a plurality of subscribers. A typical switch would include a database of control information and call processing logic in addition to its basic switching capabilities. In response to a call placed to or from a subscriber, the switch would then apply services defined by this call processing logic. For example, the service logic may indicate that all unanswered calls to a particular subscriber should be redirected to a particular voice mail server.
This approach was viewed as unwieldy, however, because a telecommunications provider needed to update the software and databases on all of its many switches in order to update services or add new services throughout its telecommunications network. And to further complicate matters, the software needed to program switches from different vendors often differed greatly.
To overcome these limitations, many telecommunications networks have now adopted an intelligent network (“IN”) approach. According to the IN approach, much of the control information and call processing logic resides in a central network location or “central control point” instead of in the multitude of switches. Each switch is then programmed with a relatively minimal set of service logic that causes the switch to query the central control point at predefined “trigger points” during call processing, providing the central control point with parameters such as an identification of the calling and called parties, for example. When the central control point receives the query message, it may execute an appropriate set of service logic and/or consult appropriate databases in order to obtain information and instructions needed to provide a special service to the call. In turn, the central control point may return a response message to the switch, instructing the switch how to handle the call.
By applying the IN approach, the call processing information that is maintained locally for reference by the switch can be minimized, since most of the service logic and feature information for the subscriber can be maintained by the central control point instead. In this way, the telecommunications switches can be quite generic but still able to carry out a variety of services. Further, changes made to service logic at the central control point can apply to a large number of switches, which makes changing or activating services and adding new services much easier and reduces the problem of differences in switches from different vendors.
An IN network typically employs a standardized set of messages for communication between the switches (or other such entities) and the central control point, in order to allow for a variety of services. This standardized set of messages may be conveyed, for instance, over an out-of-band common channel interoffice signaling (CCIS) network, according to an established signaling protocol. The most well known such protocol is Signaling System #7 (“SS7”). According to SS7, predefined messages may be coded as Transaction Capabilities Application Part (“TCAP”) messages and routed via a signaling transfer points (“STPs”) between the switches and the central control point.
The particular message set may vary depending on the type of network. For instance, traditional landline IN networks may operate according to standards embodied in Bellcore's AIN Release 0.1 and AIN Release 0.2. Typical wireless networks, on the other hand, may operate according to other standards, such as Telecommunications Industry Association (TIA)/Electronics Industry Association (EIA) Interim Standard IS-41 (“Cellular Radiotelecommunications Intersystem Operations”) and Interim Standard IS-771 (“Wireless Intelligent Network”). The entirety of each of these standards (as well as all revisions thereof) is hereby incorporated herein by reference.
In general, the trigger points and other control information about call processing for a given subscriber or group of subscribers can be defined and recorded in a database that is maintained for reference by the serving system during call processing. This set of parameters is considered a type of profile for the subscriber, or a subscriber profile. When the switch receives a request to complete a call to or from a subscriber, the switch may consult the subscriber's profile to determine whether it needs to query a central control point for call-handling instructions and/or whether it should carry out certain call processing logic itself.
A subscriber profile may define various types of trigger points and control information. At a basic level, for instance, a profile may define a so-called “all-digits trigger,” which tells the serving system to query the central control point whenever the serving system receives a call origination attempt from the subscriber. Similarly, a profile may define a termination-attempt trigger, which tells the serving system to query the central control point whenever the serving system receives a request to connect a call to the subscriber. Such global triggers can be usefully employed to give the central control point extensive control over the services that will be provided to the subscriber. For example, upon receipt of a TCAP query that is generated upon call origination, the central control point may determine that the calling subscriber has subscribed to a pre-paid call accounting service; in response, the central control point may initiate logic that will time the subscriber's call and decrement a pre-paid account balance accordingly.
The profile can define more specific triggers as well. For example, the profile may define a call origination trigger indicating that the serving system should further reference the subscriber profile to determine whether the subscriber is attempting to call a restricted destination, e.g., that the subscriber is blocked from calling a dialed number. Such a calling restriction may be desirable for group calling plans such as private branch exchange (“PBX”) or Centrex service, or for parental control, for instance. If the number is blocked, standard local service logic may direct the serving system to respond with a recorded message or other appropriate action, or the trigger may indicate that the serving system should query the central control point for guidance.
As still another example, the profile may define a call termination trigger that indicates that if the called subscriber's line is busy or there is no answer, the call should be forwarded to a particular number that is recorded in subscriber's profile. Alternatively, the termination trigger may indicate that, in response to a busy or no answer condition, the switch should query the central control point for processing instructions. In that event, the central control point may apply a set of service logic for the subscriber and decide that the call should be forwarded to a specified number (e.g., to a specified voice mail system), or that the switch should operate as normal (e.g., provide a busy signal). The central control point may then instruct the switch accordingly.
The IN concept has been applied in various types of telecommunications networks. Examples of such networks include, for instance, landline networks and wireless networks (e.g., cellular radio transmission networks).
In a traditional landline arrangement, each serving system comprises a switch referred to as a service switching point (“SSP”). The SSP is coupled via an STP network to a central control point, which is referred to as a service control point (“SCP”). The SSP maintains a subscriber profile database (e.g., a table, or more generally a data template or plurality of data templates), which defines trigger points for a given subscriber or group of subscribers. The SCP, in turn, maintains a subscriber profile database as well, indicating what service logic to provide for a particular subscriber or group of subscribers. When the SSP encounters a trigger point during call processing, it generates a TCAP query message defining the subscriber and other parameters, and it sends the query to the SCP. The SCP, in turn references its subscriber profile database, and identifies and executes the appropriate set of service logic. The SCP then generates and sends to the SSP a TCAP response message providing call handling instructions (e.g., a routing instruction, an instruction to play a message to the caller, or an instruction to simply connect the call to the dialed address.) Of course other arrangements are possible as well.
In traditional wireless networks, each serving system comprises a switch often referred to as a mobile switching center (“MSC”), as well as a subscriber profile database referred to as a visitor location register (“VLR”). A wireless subscriber station or mobile station (“MS”) may take the form of a cellular telephone, computer, pager, or personal data assistant (“PDA”), or other entity. The MS communicates over an air interface with a base station in a cell, and the base station is interconnected to the MSC, in order to provide connectivity with other points. Each mobile subscriber is registered in a home system. The home system includes a home location register (“HLR”) that defines the services and features authorized for use by the subscriber. When a mobile station roams into a given serving system (even its home system), the serving system engages in signaling communication with the HLR in the MS's home system (i) to notify the HLR where the MS is located and (ii) to obtain the MS's current profile. The serving system then stores the profile in its VLR for reference.
In wireless, the IN concept is also referred to as Wireless Intelligent Network (“WIN”). Generally speaking, as in traditional landline systems, a wireless network may include a central control point to assist one or more serving systems in handling calls. However, a WIN arrangement typically employs a unique message set and provides additional capabilities in order to facilitate mobility management and other functions that are uniquely associated with providing service for mobile subscribers.
In current practice, the central control point in a WIN arrangement may be an SCP, HLR and/or other entity. When the serving system receives a call to or from a given MS, the serving system consults the MS's profile in the VLR and determines whether to query the central control point. A trigger point in the profile may instruct the serving system to send a signaling message to one or another central control point. The signaling message is typically defined by industry standards and encapsulated in a TCAP message, and the message provides the central control point with appropriate parameters such as an identification of the MS. Upon receipt of the signaling message, the central control point may identify and execute a set of service logic for the MS and then generate and send to the serving system a response signaling message providing call handling instructions.
As an example, a serving system in a wireless network may include in the profile for a given MS an all-digits trigger that causes the serving system to query a designated SCP in response to any digit sequence dialed at the MS. If a subscriber then dials an abbreviated dialing extension, the serving system would query the designated SCP for call handling instructions, the SCP may then translate the extension into a full routing number and return the full routing number to the serving system, and the serving system would route the call accordingly. As another example, the HLR for an MS may include in the profile for the MS a particular termination trigger that directs the serving system to query a designated SCP for call handling instructions in response to a termination attempt to the MS. When the serving system receives a termination to the MS, the serving system may then query the HLR for instructions, the HLR may send the termination trigger to the serving system as an “advanced termination trigger” (i.e., one that does not normally reside in the serving system), and the serving system may respond to the trigger by querying the designated SCP for call handling instructions.
In addition, it is possible to arrange for the central control point in one system to communicate with the central control point in another system. For instance, one carrier's network may include an SCP (SCP-1) that provides call processing logic for calls placed to or from the network. However, another carrier's network may include an SCP (SCP-2) that contains service logic for a user who happens to be using the first carrier's network at the moment. (For instance, the second carrier may sell telecommunications services to a customer of the first carrier). When SCP-1 receives a TCAP query from a serving system in the first's carrier's network, it may pass a signaling message to SCP-2 to find out what to do. SCP-2 may then identify and execute a set of service logic for the subscriber and then generate and return to SCP-1 a response signaling message providing call-handling instructions. SCP-1 would then send a response TCAP message to the serving system conveying the call-handling instructions, and the serving system would carry out the instructions. Such a mediated service logic system is disclosed, for instance, in the U.S. Pat. No. 6,560,327, which has been incorporated herein by reference.
In addition to providing enhanced services for processing traditional voice and data calls, advanced telecommunications systems have also given rise to other subscriber services. One such service offered in wireless communications systems is Short Message Service (“SMS”). SMS provides for the communication of short text messages to or from a mobile station or other entity without establishing a call connection. In general, the system may allow a person to simply type in a desired text message, indicate the directory number associated with a destination mobile station, and then transmit an SMS message encapsulating the desired text message. The telecommunications network then conveys the text message to the destination mobile station, where the message is typically displayed for receipt by an end-user.
A wireless network may provide a short message service center (“SMSC”) (sometimes also referred to simply as a message center (“MC”)), which is a functional entity that stores and forwards SMS messages. The store and forward function provides a method of sending short messages to their destination recipient or storing those messages if the recipient is unavailable to receive them. This store and forward function can generally be distinguished from the real-time delivery requirements of voice calls, although SMS messages may be delivered in real time.
According to industry standards, the message center can send messages to or from a functional entity known as a short message entity (“SME”). The SME is often an application entity that resides on a MS, and may sometimes be referred to as an MS-based SME. Alternatively, the SME can comprise, or reside on, another entity in a wireless or fixed network, i.e., in whether or not part of the wireless communications network. Typically, the SME can be arranged to compose, store, dispose of, act upon, display and/or otherwise manage short messages. It can also perform signaling functions to support other delivery features such as MS location and status queries, and mapping of destination addresses. In general, a typical SMSC can forward messages to an SME, store short messages for later delivery to an unavailable SMEs, apply originating and terminating SMS supplementary services (e.g., IN services) to short messages, and serve other functions.
Each MS-based SME is usually associated with an SMSC known as the “home SMSC” in the MS's home system. The MS-based SME is qualified like an MS is qualified, with an HLR sending SME service profile information (origination and termination restrictions) to an SMS-capable serving system along with MS related profile parameters, so that the serving system can know that the MS is qualified to receive and/or send short messages. Typically, a given SMSC then maintains the mobile identification number (MIN) address information of the MSs that it serves, and the SMSC is addressable by the directory numbers (e.g., telephone numbers, IP addresses, e-mail addresses, etc.) of those MSs for mobile terminated messages. When the SMSC receives a message for one of its MSs, it may then identify the location of the MS and forward the message via the serving system to the MS.
As further background, FIGS. 1 and 2 illustrate some of the signaling involved in traditional SMS processing, as described, for instance, in Michael D. Gallagher and Randall A. Snyder, “Mobile Telecommunications Networking With IS-41” (McGraw-Hill 1997). FIG. 1 first illustrates a scenario when one mobile station, MS-A (embodying SME-A), sends an SMS message to another mobile station, MS-B (embodying SME-B). As shown in FIG. 1, at step 1, MS-based SME-A first sends an air interface message, SMD-REQUEST (SMD-REQ), embodying a short message to its serving system. At step 2, the serving system routes the short message to SME-A's SMSC (message center, “MC”), using an IS-41 SMSDeliveryPointToPoint Invoke (SMDPP) message. Such an SMDPP message may be routed using the same SS7 signaling network as is used for routing other IS-41 messages (e.g., directing the message to a network point code associated with the SMSC), and/or using TCP/IP, X.25 or another desired protocol. The SMSC then returns an “smdpp” acknowledgement message, and SME-A's serving system returns an SMD-ACK to MS-A.
At step 3, SME-A's message center might apply an originating supplementary service to the short message and then send an SMDPP message to the destination SME's SMSC. At step 4, SME-B's message center may apply a terminating supplementary service to the short message and then send an SMDPP message to SME-B's serving system. At step 5, SME-B's serving system then forwards the short message to the destination SME using the air interface SMD-REQ message, and SME-B responds with an acknowledgement SMD-ACK to signal acceptance of the SMD-REQ message.
An MS-based SME can be addressed by its host's MIN (e.g., the MIN of the mobile station on which the SME resides). In order to then determine which SMSC to route a message to for a given destination SME, an entity can maintain a table of MIN-to-SMSC addresses (e.g., MIN to SS7 destination point code, or MIN to IP address, for instance), as is often done today in IS-41 networks for routing IS-41 messages to an MS's HLR. Thus, for example, in FIG. 1, MS-A's serving system can maintain a table that indicates the address of the SME-A's SMSC for use in step 2, and SME-A's SMSC can maintain a table indicating the address of SME-B's SMSC for use in step 3.
Generally speaking, in order to terminate an SMS message to an MS-based SME, the SMSC that seeks to send the message must get a valid routing address for the system currently serving the SME. To facilitate this, IS-41 provides a special SMS_Address parameter that is conveyed to the HLR of an SMS-capable MS when the MS is registered in a new serving system. In addition, IS-41 provides an SMSRequest (SMSREQ) invoke message that can be used to request the current location of the MS-based SME.
FIG. 2 illustrates an exemplary set of processing functions that may be employed to register an MS-based SME (residing on MS-A) and to then terminate an SMS message to the SME. As shown in FIG. 2, when an SMS-capable MS is detected by a serving system, at step 1, the serving system sends a RegistrationNotification (REGNOT) invoke message to the MS's HLR. If the serving system is SMS-capable, the message includes the SMS_Address parameter, which can be used to route short messages to the serving system for delivery to the MS-based SME. For instance, if the short message transport network is SS7-based, the SMS_Address parameter may contain an SS7 point code and subsystem number. (Alternatively, as another example, if the transport network is IP (internet protocol)-based, the SMS_Address parameter may contain an IP address.) When the serving system receives an SMDPP message addressed to this point code and subsystem number, it assumes the message is intended for a visiting MS-based SME that is specifically identified by address parameters in the SMDPP message.
In turn, when an SMSC seeks to send an SMS message to an MS-based SME, at step 2, it sends an SMSREQ message to the MS's HLR. If the HLR has a valid SMS_Address for the SME, then, at step 3, the HLR returns the SMS_Address parameter in an SMSRequest return result (smsreq) message. At step 4, the SMSC then uses the SMS_Address to route the SMDPP message to the system currently serving the SME, and the serving system in turn sends the message to the SME identified in the SMDPP message, using an SMD-REQ message.
In some instances, an SME may be unavailable to receive SMS messages. This might occur, for instance, (i) if the SME (e.g., an MS-based SME) is not registered with an HLR, (ii) if the SME is registered on an SMS-incapable system, (iii) if the SME is for some reason not authorized for SMS service on the current serving system, or (iv) if the host MS is out of radio contact or intentionally inaccessible. When an SME is unavailable and the SME's HLR receives a request for the SME's SMS_Address with an SMSRequest message for instance, the HLR may indicate the unavailability to the querying SMSC, by returning an SMS_AccessDeniedReason parameter (e.g., denied, postponed or unavailable).
In an SMSRequest message, in addition to providing the destination MS's MIN (and possibly its ESN), an SMSC can provide an SMS_NotificationIndicator parameter, which advises the HLR whether or not to notify the SMSC when the MS becomes available, in case the MS is currently unavailable. When an SMSC sends an SMSRequest message for an MS-based SME to the MS's HLR and the MS is unavailable, the HLR may then store an indication that the SMSC has a message waiting for the MS, unless the SMS_NotificationIndicator parameter indicates that the HLR need not notify the SMSC when the MS becomes available. When the MS then becomes available, the HLR may send an SMSNotification message to the SMSC, providing the SMS_Address of the MS-based SME, and advising the SMSC that it may send the stored message to the SME.
As suggested above, SMS service can involve communication over various transport networks, such as conventional SS7 networks, IP networks (e.g., the Internet), and X.25 networks, for instance. In this regard, for example, an MSC or SMSC may be programmed as, or coupled with, an “interworking function,” to convert SMS messages from an SS7-encapsulated form into a form appropriate for IP-transport. This may involve converting an SMS message into a stream of TCP/IP packets for transmission over the IP transport network. This arrangement may allow network access to external IP applications (i.e., SMEs) as well as inexpensive IP access between SMSCs belonging to different networks.
For instance, an SMS message generated in an SS7-based network can be conveyed over an IP network to a POP3 e-mail server, which can then convert the message into an Simple Mail Transfer Protocol (“SMTP”) e-mail message and forward the e-mail message to a designated e-mail recipient (which may be considered a type of SME). As another example, text messages generated and conveyed in an IP network (e.g., by an e-mail client) might be conveyed via the interworking function to an SME in an SS7 network. An Internet Service Provider (ISP) may thus allow an Internet e-mail subscriber to send a text message to a designated MS-based SME referenced by a given directory number, for instance. As still another example, an SMSC or MSC in one carrier's network might convey an SMS message, via an interworking function and an IP transport network, to an SMSC or MSC in another carrier's network, and the other SMSC or MSC may then deliver the SMS message to a designated recipient.